home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0073.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.9 KB  |  68 lines
  1. > Date: Tue, 24 Mar 92 09:46:21 PST
  2. > From: Jonny Goldman <jonathan@think.com>
  3.  
  4. Jonny,
  5.  
  6. This is relevant to the WAIS-FTP work Jim is doing.
  7.  
  8. Unfortunately none of the WAIS crowd could get to discussions at the IETF -- though  
  9. John Curran represented the WAIS side. Those discussions were very interesting. 
  10.  
  11.  
  12. The data model of WAIS (documents in databases) could be deconstrained to allow  
  13. documents themselves to be or contain lists of documents, and for lists of  
  14. documents to point to things other than documents in the same database.
  15.  
  16. This is the way the second part can work.  Normally, a search returns a list of  
  17. doc-ids, each one (basically) like
  18.  
  19.     /usr/local/lib/wais/mydatabase/fred/myfile.txt
  20.  
  21. which is in fact a filename. There's a load of other stuff in there which we can  
  22. ignore for now.  What a WAIS search needs to be able to do, when you are pointing
  23. to files, is to return a pointer to a file in FTP say. We do that in two steps.
  24. First, we recognise that that id is local to the conext of a wais server on host  
  25. myhost and port myport. When the server returns that string, the client
  26. uses knowledge of the context in which it was quoted to exapnd that to
  27.  
  28.     wais://myhost.dom.net:myport/usr/local/lib/wais/mydatabase/fred/myfile.txt
  29.  
  30. This is a refernece you can quote to anyone as it makes sense anywhere. No context.
  31. I called it a UDI but we'll have to change the name. Document Access Token maybe.
  32. It's like Brewster's proposal but extendable to other protocols.  [Yes, WAIS is a  
  33. good protocol but there are others. Including name servers and directories which  
  34. will be needed for long-lived but movable documents.]
  35.  
  36. Now suppose one day a server returns a doc-id INCLUDING the protocol, host, etc.  
  37. For example, your WAIS FTP engine (like the ARCHIE WAIS) returns what are basically
  38. pointers to files. Just now, because of the constraints of the model, it has to  
  39. return a part of a file within the database. Suppose we change that, so that
  40. in your case it just returns a doc-id which specifies anonymous ftp access, like:
  41.  
  42.     file://otherhost.com/pub/doc/mydoc.txt
  43.  
  44. The client has a general retrieval engine which can accept doc-ids in many domains  
  45. -- not just WAIS. That allows it to go out over a different protocol to retrieve  
  46. the object.
  47.  
  48. This is the way WWW and Gopher work.  They are open systems -- you can link into
  49. any other system within reason.  That's why the fuss about universal document  
  50. identifiers.  Maybe the WAIS people would to incorporate them -- that is, just
  51. make sure that the normal WAIS server return things which are -- like the one
  52. above -- special cases of the more general syntax.
  53.  
  54. I haven't had much comment from the WAIS side about the UDIs, but I'd like to have  
  55. some. (file://info.cern.ch/pub/www/doc/udi1.ps was background for the IETF  
  56. discussions.) We plan a small working group hacking out the details before an RFC  
  57. is submitted.
  58.  
  59.  
  60. > I like the idea of generalized interfaces, customized servers.
  61.  
  62. You bet!
  63.  
  64.  
  65. - Tim BL
  66.  
  67.  
  68.